home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
InfoMagic Standards 1994 January
/
InfoMagic Standards - January 1994.iso
/
ccitt
/
1988
/
troff
/
6_9_03.tro
< prev
next >
Wrap
Text File
|
1991-12-13
|
86KB
|
3,668 lines
.rs
.\" Troff code generated by TPS Convert from ITU Original Files
.\" Not Copyright ( c) 1991
.\"
.\" Assumes tbl, eqn, MS macros, and lots of luck.
.TA 1c 2c 3c 4c 5c 6c 7c 8c
.ds CH
.ds CF
.EQ
delim @@
.EN
.nr LL 40.5P
.nr ll 40.5P
.nr HM 3P
.nr FM 6P
.nr PO 4P
.nr PD 9p
.po 4P
.rs
\v | 5i'
.sp 2P
.LP
\fBRecommendation\ Q.775\fR
.RT
.sp 2P
.sp 1P
.ce 1000
\fBGUIDELINES\ FOR\ USING\ TRANSACTION\ CAPABILITIES\fR
.EF '% Fascicle\ VI.9\ \(em\ Rec.\ Q.775''
.OF '''Fascicle\ VI.9\ \(em\ Rec.\ Q.775 %'
.ce 0
.sp 1P
.ce 1000
\fR \fI(Melbourne, 1988)\fR
.sp 9p
.RT
.ce 0
.sp 1P
.LP
\fB1\fR \fBIntroduction\fR
.sp 1P
.RT
.sp 1P
.LP
1.1
\fIGeneral\fR
.sp 9p
.RT
.PP
The purpose of this Recommendation is to provide guidelines to
potential users of Transaction Capabilities (TC\(hyusers). The examples
given are illustrations only; they indicate how an application may use
TCAP, not how TCAP must be used in all cases. The technical basis of this
document are
Recommendations\ Q.771 to\ Q.774; in case of misalignment, these should be
considered as the primary reference.
.PP
The main purpose of TCAP is to provide support for interactive
applications in a distributed environment. TCAP is based on
Recommendations\ X.219 and\ X.229 (ROSE) enhanced as necessary to provide the
services needed by TC\(hyusers. Interactions between distributed application
entities are modelled by Operations. An operation is invoked by an
(originating) entity: the other (destination) entity attempts to execute the
operation and possibly returns the outcome of this attempt.
.PP
The semantics of an operation (represented by its name and parameters)
is not relevant to TCAP; TCAP provides facilities which are independent
of any particular operation. The TC\(hyuser, when defining an application,
must:
.RT
.LP
1)
select operations;
.LP
2)
select TCAP facilities to support these operations. Such
facilities include the handling of individual operations, and
the ability to have a number of related operations attached to
an association between TC\(hyusers, called a dialogue;
.LP
3)
define the application script.
.PP
This Recommendation describes the selection process of defining
and using operations. The operations appearing hereafter are fictitious, and
are taken for illustration purposes only. Also described are the facilities
offered by TCAP for handling one or a sequence of operations in a dialogue.
The definition of specific sequences of operations belongs to the application
protocol definition and is beyond the scope of this Recommendation; however,
Chapter\ 4 gives a brief indication of what information an application
specification should contain.
.PP
TCAP services are made accessible to TC\(hyusers via primitives; these
primitives model the interface between TCAP and its users, but do not constrain
any implementation of this interface.
.RT
.sp 1P
.LP
1.2
\fIEnvironment\fR
.sp 9p
.RT
.PP
TCAP defines the end\(hyto\(hyend protocol between TC\(hyusers which may
be located in a Signalling System No.\ 7 network, and/or another network
supporting TCAP protocols.
.PP
Two broad categories of users have been considered (see
Recommendation\ Q.771, \(sc\ 1.3.2). Only the first category is considered
here,
i.e.\ those which are real\(hytime sensitive users, and do not need to exchange
large amounts of data. It is considered that for these users, protocols
defined for OSI layers\ 4 to\ 6 in the X\ series of Recommendations would
result in
excessive overheads and hence are not used. A basic service has been specified,
using a connectionless network service approach. Other categories of users
might require connection\(hyoriented network and higher layer services.
.PP
As a result, TCAP cannot support all kinds of applications, and a
number of applications will still require more elaborate services such as
specified in the X\ series of Recommendations. Besides indicating what
TCAP can do, this Recommendation indicates what the connectionless approach
cannot do, in order to help the application designer choose how to support
an
application.
.RT
.sp 2P
.LP
\fB2\fR \fBOperations\fR
.sp 1P
.RT
.sp 1P
.LP
2.1
\fIDefinition\fR
.sp 9p
.RT
.PP
An operation is invoked by an originating TC\(hyuser to request a
destination TC\(hyuser to perform a given action.
.PP
A class is attached to an operation. This indicates whether either a successful
outcome (result), or an unsuccessful outcome (error), or both, or
none have to be reported by the destination. The outcome is reported in a
result.
.bp
.PP
As well as the class, the definition of the operation includes a timer
value indicating when the operation should be completed. This value is
not
indicated to the remote TC\(hyuser; it is assumed that the application at both
ends has a common understanding of the operations in use.
.PP
An \fBoperation\fR is defined by:
.RT
.LP
\(em
its operation code and the type of any parameters associated with the
operation request;
.LP
\(em
its class;
.LP
\(em
if the class requires report of success, the possible results corresponding
to successful executions are defined by a list of parameters;
.LP
\(em
if the class requires report of failure, the possible results corresponding
to situations where the operation could not be executed
completely by the remote TC\(hyuser. Each such situation is identified by a
specific error cause; the list of these error causes is part of the operation
definition. Diagnostic information can be added to the error cause: if
present, it is part of the definition;
.LP
\(em
the list of possible linked operations, if replies consisting of linked
operations are allowed for this operation. Linked operations have to be
described separately;
.LP
\(em
a timer value indicating the interval by which the operation has to be
completed. This timer value is used to manage the component ID
associated with the operation invocation.
.sp 2P
.LP
2.2
\fIExamples\fR
.sp 1P
.RT
.sp 1P
.LP
2.2.1
\fISimple operations\fR
.sp 9p
.RT
.PP
\fINote\fR \ \(em\ The operation invocation should fit into one message,
and so should a report of unsuccessful outcome. Reports of success may
be segmented using Return Result\(hyNot last and Return Result\(hyLast.
.RT
.sp 1P
.LP
\fIClass 1 (both success and failure reported):\fR
.sp 9p
.RT
.PP
Translate a freephone number into a called subscriber number;
return the called number if the translation can be performed, otherwise
indicate why it cannot; time allocated: 2\ seconds.
.PP
No reply being received when the timer expires indicates an abnormal situation
(e.g.\ the operation invocation may have been lost): the local TC\(hyuser
is informed (operation cancel by TCAP).
.RT
.sp 1P
.LP
\fIClass 2 (only failure reported):\fR
.sp 9p
.RT
.PP
Perform a routine test and send a reply only in case something went wrong;
time allocated: 1\ minute.
.PP
In the case of a class 2 operation, the TC\(hyuser is informed if no
result has been received when the timer expires. This is interpreted as a
successful outcome, even if the invocation was lost. This aspect should be
considered when selecting class\ 2.
.RT
.sp 1P
.LP
\fIClass 3 (only success reported):\fR
.sp 9p
.RT
.PP
Perform a test: this corresponds to a pessimistic view, where
failure is considered as the default option, not requiring any reply.
.PP
Timer expiry is indicated to the TC\(hyuser: this should be interpreted
by the TC\(hyuser as a failure of the operation (but is considered normal
by TC, which considers that the operation has terminated). This aspect
should be
considered when selecting class\ 3.
.RT
.sp 1P
.LP
\fIClass 4 (neither success, nor failure reported):\fR
.sp 9p
.RT
.PP
Send a warning, without expecting a reply or acknowledgement of any kind.
.PP
In this case, a result never arises from the invocation of the
operation. The TC\(hyuser relies upon TCAP and the network to deliver the
invocation. Notification of the timer expiry is a local matter.
.PP
The diagrams in Figure 1/Q.775 illustrate possible sequences of
primitives as seen by the TC\(hyuser originating an operation.
.bp
.RT
.LP
.rs
.sp 47P
.ad r
\fBFigure 1/Q.775, (N), p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
\fIComparison with ROSE (Recommendation X.219) operation classes\fR :
.sp 9p
.RT
.PP
ROSE provides for five classes of operations: classes 2 to 5,
called
asynchronous classes, are identical to classes\ 1 to\ 4 of TCAP. ROSE's
class\ 1 is a synchronous class; it has no counterpart in TCAP, where full\(hyduplex
exchanges of components are considered. However, a TC\(hyuser can decide to
operate in a synchronous manner (see \(sc\ 3.2.1).
.RT
.sp 2P
.LP
2.2.2
\fIMore sophisticated operations\fR
.sp 1P
.RT
.sp 1P
.LP
\fIOperations with segmented results\fR
.sp 9p
.RT
.PP
A successfull result may be divided into several segments, each of which
is indicated to the originator of the operation by one primitive. This
facility, using the TC\(hyRESULT\(hyNL primitive, can be used by TC\(hyusers
to overcome the absence of segmentation in the underlying layers. The last
segment is
indicated by the
TC\(hyRESULT\(hyL primitive.
.PP
The report of an error cannot be segmented.
.PP
Apart from abnormal situations, responses are delivered to the remote TC\(hyuser
in the order in which they have been passed to TCAP by the sending
TC\(hyuser.
.PP
TC cannot identify a specific segment in the case of a segmented
result.
.PP
Example E1: An operation requests the execution of a test. The result of
a correct execution is segmented in three parts\ P1, P2 and\ P3 to be returned
to the originator.
.PP
A possible primitive sequence for example E1 is given in
Table\ 1/Q.775
.RT
.ce
\fBH.T. [T1.775]\fR
.ce
TABLE\ 1/Q.775
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(78p) | cw(78p) .
TC USER A TC USER B
_
.T&
lw(78p) | lw(78p) .
{
TC\(hyINVOKE req
(Test, Class = 1)
} {
.
TC\(hyINVOKE ind
(Test)
TC\(hyRESULT\(hyNL req
(P1)
}
_
.T&
lw(78p) | lw(78p) .
TC\(hyRESULT\(hyNL ind (P1) . TC\(hyRESULT\(hyNL req (P2)
_
.T&
lw(78p) | lw(78p) .
TC\(hyRESULT\(hyNL ind (P2) . TC\(hyRESULT\(hyL req (P3)
_
.T&
lw(78p) | lw(78p) .
TC\(hyRESULT\(hyL ind (P3)
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 1/Q.775 [T1.775], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.PP
The diagram in Figure 2/Q.775 illustrates possible sequences of
primitives seen by the originator of an operation (class\ 1) with segmented
results.
.LP
.rs
.sp 31P
.ad r
\fBFigure 2/Q.775, (N), p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
\fILinked operations\fR
.sp 9p
.RT
.PP
Another extension to the basic operation scheme is the ability to link
an operation invocation to another operation invocation.
.PP
Typically, this facility covers situations where the destination of
the original (linked\(hyto) operation requires additional information in
order to process this operation: this is the case where menu facilities
are used (menu facilities allow a user to make a sequence of choices, each
being dependent on the previous ones).
.PP
Example E2: The operation is the execution of a test with several
options; before the test is executed, these options are offered for selection
to the test originator (TC\(hyuser\ A). Two operations are nested: operation\
1 is the test; operation\ 2 is the option selection. TC\(hyuser\ A first
responds to
operation\ 2 before TC\(hyuser\ B can perform the test with the indicated
option(s).
.bp
.PP
A possible primitive sequence for example E2 is given in
Table\ 2/Q.775.
.RT
.ce
\fBH.T. [T2.775]\fR
.ce
TABLE\ 2/Q.775
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(80p) | cw(148p) .
TC USER A TC USER B
_
.T&
lw(80p) | lw(74p) | lw(74p) .
{
TC\(hyINVOKE req
(Test, Class = 1)
} {
.
TC\(hyINVOKE ind
(Test)
TC\(hyINVOKE req
(Option\(hyselection, Class = 1)
} {
Operation 1 begin
Operation 2 begin
}
_
.T&
lw(80p) | lw(74p) | lw(74p) .
{
TC\(hyINVOKE ind
(Option\(hyselection)
TC\(hyRESULT\(hyL req
(Options)
} {
.
TC\(hyRESULT\(hyL ind
(Options)
TC\(hyRESULT\(hyL req
(Test\(hyresult)
} . Operation 2 end
_
.T&
lw(80p) | lw(74p) | lw(74p) .
{
TC\(hyRESULT\(hyL ind
(Test\(hyresult)
} Operation 1 end
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 2/Q.775 [T2.775], p.\fR
.sp 1P
.RT
.ad b
.RT
.PP
There is no limit to the number of operation invocations which may be linked
to a given operation invocation.
.PP
Note that when an operation B is linked to another operation A, they do
not have to be nested. The only condition is that the invocation of\ B
should take place before the outcome of\ A is reported; however, operation\
B does not have to terminate before operation\ A.
.RT
.sp 2P
.LP
2.3
\fIComponent\(hyrelated facilities offered to TC\(hyusers\fR
.sp 1P
.RT
.sp 1P
.LP
2.3.1
\fIInvocation\fR
.sp 9p
.RT
.PP
So far, operations have been considered from the static point of
view. Invocation introduces a dynamic aspect: a specific invocation of an
operation has to be differentiated from other possible concurrent invocations
of the same or of another operation.
.PP
Each particular activation of an operation is identified by a
component ID. This component ID must be non ambiguous. It is selected by the
TC\(hyuser which originates the operation invocation, and passed to the
destination TC\(hyuser, which will reflect it in its reply(ies): therefore it
correlates the replies to an invocation, and the invocation itself.
.PP
The TC\(hyuser is free to assign any value to the component ID (index,
address, . | | ).
.PP
The component ID associated with an invocation becomes reusable when the
last or only segment of a result is received, or when certain abnormal
situations are indicated by TCAP; however, the value should not be reallocated
immediately for another operation activation, as immediate reallocation
would prevent the correct handling of some situations (see below).
.bp
.PP
The period during which a component ID is released, but cannot be
reallocated, is called the freezing period.
.PP
As component IDs receive their value dynamically at the time the
operation is invoked, their value cannot appear in the specification of the
application protocols; rather, a \*Qlogical\*U value, to which a real value is
substituted at execution time, should be indicated in order to identify an
operation in a single flow.
.PP
Taking component IDs into consideration, the sequence of primitives
for example E2 above becomes as shown in Table\ 3/Q.775.
.RT
.ce
\fBH.T. [T3.775]\fR
.ce
TABLE\ 3/Q.775
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(78p) | cw(78p) .
TC USER A TC USER B
_
.T&
lw(78p) | lw(78p) .
{
TC\(hyINVOKE req
(1, Test, Class = 1)
} {
.
TC\(hyINVOKE ind
(1, Test)
TC\(hyINVOKE req
(2, 1, Option\(hyselection, Class = 1)
}
_
.T&
lw(78p) | lw(78p) .
{
TC\(hyINVOKE ind
(2, 1, Option\(hyselection)
TC\(hyRESULT\(hyL req
(2, Options)
} {
.
TC\(hyRESULT\(hyL ind
(2, Options)
TC\(hyRESULT\(hyL req
(1, Test\(hyresult)
}
_
.T&
lw(78p) | lw(78p) .
{
TC\(hyRESULT\(hyL ind
(1, Test\(hyresult)
}
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 3/Q.775 [T3.775], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
where the first parameter of a primitive indicates an invoke ID. When both
parameters have to be present, the second one is the linked ID. This is
a pure notational convention.
.sp 1P
.LP
2.3.2
\fICancel\fR \fI(by the TC\(hyuser)\fR
.sp 9p
.RT
.PP
The TC\(hyuser requesting invocation of an operation may stop the
activity associated with the corresponding component\ ID, for any reason it
finds appropriate. However, cancel should in principle be reserved for
abnormal situations: the normal method for terminating an operation is
to receive a
result or to terminate on timer expiry.
.PP
Cancelling has local effect only: it does not prevent the remote
TC\(hyuser from sending replies to a cancelled operation. When received, these
replies will be rejected by TCAP, as illustrated in the following, which
represents a sequence of primitives for the example\ E1 defined above, where
TC\(hyuser\ A cancels the test after receiving the first segment of the
result.
.PP
In Table 4/Q.775, part P2 is not received by TC\(hyuser\ A: TCAP detects
a reject situation before delivering it, and any attempt by TC\(hyuser\
B to send
more replies is rejected at A's side.
.bp
.RT
.ce
\fBH.T. [T4.775]\fR
.ce
TABLE\ 4/Q.775
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(78p) | cw(78p) .
TC USER A TC USER B
_
.T&
lw(78p) | lw(78p) .
{
TC\(hyINVOKE req
(1, Test, Class = 1)
} {
.
TC\(hyINVOKE ind
(1, Test)
TC\(hyRESULT\(hyNL req
(1, P1)
}
_
.T&
lw(78p) | lw(78p) .
{
TC\(hyRESULT\(hyNL ind
(1, P1)
Cancel decision:
TC\(hyCANCEL req
(1)
TC\(hyL\(hyREJECT ind
(1, Problem Code)
....
} {
.
TC\(hyRESULT\(hyNL req
(1, P2)
....
}
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 4/Q.775 [T4.775], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 3
.sp 1P
.LP
2.3.3
\fIReject\fR \fI(by the TC\(hyuser)\fR
.sp 9p
.RT
.PP
A TC\(hyuser may decide to reject a component for any reason it finds appropriate,
e.g.\ application protocol error, parameter missing in an operation or
a reply,\ etc.
.PP
TCAP covers a number of cases, identified by the list of Problem Codes
in Recommendation\ Q.773. In any of these cases, which correspond to situations
where an operation or a reply is not correctly formatted, the TC\(hyuser
may use the reject facility. Alternately, he may decide to return a failure
indication (error component), which allows more detailed error and diagnostic
information.
.PP
Reject of an operation invocation, or of a result, affect the whole
operation: no more replies will be accepted for this invocation. Reject of a
linked operation does not affect the linked\(hyto operation.
.PP
This is illustrated in Table\ 5/Q.775 where, in example E2, TC\(hyuser\
A did not expect the option selection process (it may be an optional feature),
and rejects the operation with the Problem Code \*QUnexpected Linked Operation\*U.
TC\(hyuser\ B may then decide to execute the test assuming a default
option.
.bp
.RT
.ce
\fBH.T. [T5.775]\fR
.ce
TABLE\ 5/Q.775
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(78p) | cw(78p) .
TC USER A TC USER B
_
.T&
lw(78p) | lw(78p) .
{
TC\(hyINVOKE req
(1, Test, Class = 1)
} {
.
TC\(hyINVOKE ind
(1, Test)
TC\(hyINVOKE req
(2, 1, Option\(hyselection, Class = 1)
}
_
.T&
lw(78p) | lw(78p) .
{
TC\(hyINVOKE ind
(2, 1, Option\(hyselection)
TC\(hyU\(hyREJECT req
(2, Problem Code)
}
_
.T&
lw(78p) | lw(78p) .
{
TC\(hyU\(hyREJECT ind
(2, Problem Code)
TC\(hyRESULT\(hyL req
(1, Test\(hyresult)
}
_
.T&
lw(78p) | lw(78p) .
{
TC\(hyRESULT\(hyL ind
(1, Test\(hyresult)
}
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 5/Q.775 [T5.775], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 3
.PP
When an operation invocation is rejected, the TC\(hyuser may decide to
reinvoke it (e.g.\ the invoke component was corrupted); this would be a
new invocation (new Invoke ID). It may also decide to abort the dialogue.
A very
simple dialogue (a question and a response) may not define any recovery
mechanisms, except when the operation is of critical importance (e.g.\ a
database update).
.sp 2P
.LP
2.4
\fIComponent\(hyrelated abnormal situations\fR
.sp 1P
.RT
.sp 1P
.LP
2.4.1
\fIComponent loss\fR
.sp 9p
.RT
.PP
TCAP assumes a very low probability of message loss in the network; if
this probability is too high for an application, it should use the
connection\(hyoriented network service approach. If some protocol information
needs an upgraded quality of service (e.g.\ charging information), the
application should introduce its own mechanisms to obtain higher reliability
for this information.
.bp
.RT
.sp 1P
.LP
\fILoss of an operation invocation\fR
.sp 9p
.RT
.PP
The Table 6/Q.775 sequence illustrates the case, in example E1,
where no response to the test is received before the time limit
expires.
.RT
.ce
\fBH.T. [T6.775]\fR
.ce
TABLE\ 6/Q.775
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(78p) | cw(78p) .
TC USER A TC USER B
_
.T&
lw(78p) | lw(78p) .
{
TC\(hyINVOKE req
(1, Test, Class = 1)
}
_
.T&
lw(78p) | lw(78p) .
{
Time limit:
TC\(hyL\(hyCANCEL ind
(1)
}
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 6/Q.775 [T6.775], p.\fR
.sp 1P
.RT
.ad b
.RT
.PP
When a class 1 operation is lost, the TC\(hyuser is informed when the timer
asociated with the operation expires. When a class\ 1 operation with a
single result is lost, TCAP cannot indicate whether either the operation
invocation, or the reply, was lost. If the application needs to discriminate
between these two cases, it should do it in the application protocol
(e.g.\ using the time\(hystamping or acknowledging the operation invocation
before replying to it).
.PP
For a class 2 operation, loss will be considered as a success (whether
the invocation, or the failure report, was lost). This, considering the
probability of loss, may be acceptable for non critical operations
(e.g.\ statistical measurements).
.PP
For a class 3 operation, loss is treated in the same way as operation failure,
whether the invocation, or the success report, has been lost.
.PP
For a class 4 operation, loss will not be visible to TCAP.
.RT
.sp 1P
.LP
\fILoss of a result\fR
.sp 9p
.RT
.LP
\(em
Loss of a non final result is never detected by TCAP.
.LP
\(em
Loss of a final result will eventually be indicated to the
TC\(hyuser when the time limit is reached, but cannot always be
unambiguously interpreted as the loss of a reply; of no non final
result has been received, it may be that the invocation was
lost.
.sp 1P
.LP
\fILoss of a linked operation\fR
.sp 9p
.RT
.PP
The loss of a linked operation has the same effect as the loss of a non\(hylinked
operation. It has no effect on the linked\(hyto operation.
.RT
.sp 1P
.LP
\fILoss of a reject component\fR
.sp 9p
.RT
.PP
This case should be extremely infrequent, and no application should try
to recover from such a situation. If the lost reject concerns an operation
invocation, then when the operation timed out the TC\(hyuser which invoked
the
operation will consider that the invocation (or the reply) was lost, and
react accordingly; if it concerns a reply, the originator of the reply
will consider that it was correct: it will be up to the originator of the
operation to detect the loss.
.RT
.sp 1P
.LP
2.4.2
\fIComponent duplication\fR
.sp 9p
.RT
.PP
As message duplication is very infrequent in the Signalling System No.\
7 network, scripts for No.\ 7 applications need not define sophisticated
scenarios in anticipation of such situations. However, any application
in which duplication would be unacceptable should either define its own
duplication
detection mechanism or use a connection\(hyoriented service.
.bp
.RT
.sp 1P
.LP
\fIDuplicate operation invocation\fR
.sp 9p
.RT
.PP
When an operation invocation is duplicated (by the service
provider), the destination TC\(hyuser (B) may, or may not, detect the
duplication:
.RT
.LP
\(em
TC\(hyuser B detects the duplication: the best it can do in this case
is to ignore the duplicate; rejection could be interpreted by the remote
TC\(hyuser as rejection of the original invocation;
.LP
\(em
TC\(hyuser B does not detect the duplication: this may happen
when there is a master\(hyslave relationship between\ A and\ B, and\ B
executes the operation with no knowledge of the context.
.PP
Assuming the second case in exaple E1, a possible sequence could be as
given in Table\ 7/Q.775.
.ce
\fBH.T. [T7.775]\fR
.ce
TABLE\ 7/Q.775
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(80p) | cw(148p) .
TC USER A TC USER B
_
.T&
lw(80p) | lw(74p) | lw(74p) .
{
TC\(hyINVOKE req
(1, Test, Class = 1)
TC\(hyRESULT\(hyNL ind
(1, P1)
TC\(hyRESULT\(hyNL ind
(1, P1)
A detects an abnormal situation and rejects:
TC\(hyU\(hyREJECT req
(1, Problem Code)
TC detects an abnormal situation and rejects P2:
TC\(hyL\(hyREJECT ind
(1, Problem Code)
} {
.
TC\(hyINVOKE ind
(1, Test)
TC\(hyINVOKE ind
(1, Test)
TC\(hyRESULT\(hyNL req
(1, P1)
TC\(hyRESULT\(hyNL req
(1, P1)
TC\(hyRESULT\(hyNL req
(1, P2)
TC\(hyU\(hyREJECT ind
(1, Problem Code)
} {
.
Undetected duplication of invocation
}
_
.T&
lw(80p) | lw(74p) | lw(74p) .
{
TC\(hyR\(hyREJECT ind
(1, Problem Code)
}
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 7/Q.775 [T7.775], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.PP
In this sequence, TC\(hyuser B considers two independent test
invocations, and responds to each of them. The first result P1 is accepted;
TC\(hyuser A detects that P1 is received a second time, and rejects it; this
terminates the operation, and causes result P2 to be rejected when received
(reject by TCAP). Therefore, both activities at B's side will terminate on
receipt of rejects.
.sp 1P
.LP
\fIDuplicate non\(hyfinal result\fR
.sp 9p
.RT
.PP
If a non\(hyfinal result is duplicated, TCAP cannot detect it, and
will deliver it twice to the TC\(hyuser. Detection of this situation is left to
the application.
.RT
.sp 1P
.LP
\fIDuplicate final result\fR
.sp 9p
.RT
.PP
If a final result is duplicated, TCAP can detect the situation: the second
final result is considered as abnormal (the operation has been
terminated by the first \*Qfinal\*U result), and TCAP rejects it.
.PP
Table 8/Q.775 shows a sequence for example E1 where the third segment of
the result is duplicated (by the network).
.RT
.ce
\fBH.T. [T8.775]\fR
.ce
TABLE\ 8/Q.775
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(78p) | cw(78p) .
TC USER A TC USER B
_
.T&
lw(78p) | lw(78p) .
{
TC\(hyINVOKE req
(1, Test, Class = 1)
TC\(hyRESULT\(hyNL ind
(1, P1)
TC\(hyRESULT\(hyNL ind
(1, P2)
TC\(hyRESULT\(hyL ind
(1, P3)
Duplication of P3:
TC\(hyL\(hyREJECT ind
(1, Problem Code)
} {
.
TC\(hyINVOKE ind
(1, Test)
TC\(hyRESULT\(hyNL req
(1, P1)
TC\(hyRESULT\(hyNL req
(1, P2)
TC\(hyRESULT\(hyL req
(1, P3)
}
_
.T&
lw(78p) | lw(78p) .
{
TC\(hyR\(hyREJECT ind
(1, Problem Code)
}
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 8/Q.775 [T8.775], p.\fR
.sp 1P
.RT
.ad b
.RT
.PP
Comment: Discarding of duplicates in all cases by TCAP would
probably appear as a nicer issue. However, it should be noted that:
.LP
1)
it would require another degree of complexity in TCAP, which contradicts
the basic characteristics of TCAP in the
connectionless approach;
.LP
2)
it corresponds to a situation which is
extremely infrequent, at least in the No.\ 7
network.
.PP
To cover these situations when required by an application, it
would be better to use a connection\(hyoriented network service approach, since
duplication could then be detected and handled at the lower layers.
.bp
.sp 1P
.LP
2.4.3
\fIComponent missequencing\fR
.sp 9p
.RT
.PP
For TCAP, the order of segmented results is not relevant: if the
order is important to the TC\(hyuser, appropriate mechanisms should be
defined in the application protocol (e.g.\ by introducing a numbering scheme
to identify
intermediate replies in a parameter of these replies, or by using a
connection\(hyoriented service).
.PP
Due to missequencing, a non final result may arive after a final
result: when this occurs the non final result is rejected by TCAP.
.PP
The sequence in Table\ 9/Q.775 illustrates what happens in example E1 when
the last part of the result is received before the second one: both
TC\(hyusers are informed.
.RT
.ce
\fBH.T. [T9.775]\fR
.ce
TABLE\ 9/Q.775
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(78p) | cw(78p) .
TC USER A TC USER B
_
.T&
lw(78p) | lw(78p) .
{
TC\(hyINVOKE req
(1, Test, Class = 1)
} {
.
TC\(hyINVOKE ind
(1, Test)
TC\(hyRESULT\(hyNL req
(1, P1)
}
_
.T&
lw(78p) | lw(78p) .
{
TC\(hyRESULT\(hyNL ind
(1, P1)
TC\(hyRESULT\(hyL ind
(1, P3)
Missequenced result:
reject
TC\(hyL\(hyREJECT ind
(1, Problem Code)
} {
.
TC\(hyRESULT\(hyNL req
(1, P2)
TC\(hyRESULT\(hyL req
(1, P3)
}
_
.T&
lw(78p) | lw(78p) .
{
TC\(hyR\(hyREJECT ind
(1, Problem Code)
}
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 9/Q.775 [T9.775], p.\fR
.sp 1P
.RT
.ad b
.RT
.PP
If a linked operation invocation is received after the final
result of the linked\(hyto operation (as a result of a missequencing),
the linked operation is rejected.
.PP
TCAP assumes a very low probability of missequencing; if the
supporting network is not satisfactory in this respect, the connection\(hyoriented
network service approach should be considered.
.RT
.sp 1P
.LP
2.4.4
\fIReject of a component by TCAP\fR
.sp 9p
.RT
.PP
A general principle when TCAP receives a component (operation
invocation or reply) which is either not formatted correctly, or received
out of context (e.g.\ a reply without a prior operation invocation), is
to reject
it, which means that:
.RT
.LP
1)
the destination of the faulty component is first informed of
the situation; TCAP provides whatever information is available
on the nature of the component being rejected
.LP
2)
in reaction to this, the TC\(hyuser may decide to abort,
continue, or end the dialogue. In the last two cases, when the
TC\(hyuser notifies TCAP of its decision, the peer TC\(hyuser is
informed of the reject.
.bp
.PP
Possible cases of reject by TCAP have been encountered in the
previous sections. Whenever the component\ ID is recognised, rejection
by TCAP causes the termination of the operation: a possible recovery is
a new
invocation of the terminated operation. When the rejected component is not
identifiable, only the local TC\(hyuser is informed, and abort of the dialogue
may be the appropriate reaction.
.sp 1P
.LP
2.4.5
\fIOperation timer expiry\fR
.sp 9p
.RT
.PP
When TCAP informs the TC\(hyuser of timer expiry (TC\(hyL\(hyCANCEL
indication), it indicates that no more information related to the operation
invocation (in particular, no reject) can be received. If the peer entity
still sends information in relation with this invocation, this information
will be
discarded when received, provided that the component\ ID of the cancelled
operation has not been reallocated. Premature reallocation of component\ ID
values is normally avoided by correctly setting timer values: in order to
.PP
compensate for uncertainties in the amount of time required to send information
from TC\(hyuser to another without accounting for the absolute worst case
(which is also in general the most unlikely), an implementation\(hydependent
mechanism
avoiding premature reallocation of component IDs is required.
.PP
Timer expiry indication corresponds to an abnormal situation only in the
case of a class\ 1 operation. The TC\(hyuser is then aware that either
the
invocation, or the reply, was lost. If no undesirable side effects arise,
another invocation of the same operation can take place after timer expiry.
This is illustrated by the sequence in Table\ 10/Q.775 for example\ E1.
.RT
.ce
\fBH.T. [T10.775]\fR
.ce
TABLE\ 10/Q.775
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(78p) | cw(78p) .
TC USER A TC USER B
_
.T&
lw(78p) | lw(78p) .
{
TC\(hyINVOKE req
(1, Test, Class = 1)
} . TC\(hyINVOKE ind (1, Test)
_
.T&
lw(78p) | lw(78p) .
{
Timer expiry:
TC\(hyL\(hyCANCEL ind
(1)
TC\(hyINVOKE req
(2, Test, Class = 1)
}
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 10/Q.775 [T10.775], p.\fR
.sp 1P
.RT
.ad b
.RT
.PP
Timer expiry for a class 2 operation indicates that no failure was received
nor will be accepted for this invocation: it is a definite indication of
success (for class\ 2). A parallel situation applied to class\ 3 in case
of
failure. The indication of timer expiry for a class\ 4 operation is a local
decision.
.sp 2P
.LP
\fB3\fR \fBDialogues\fR
.sp 1P
.RT
.PP
Whenever one of the operation handling primitives considered in \(sc\ 2
is issued, a request is passed to TCAP, but nothing is sent to the remote
TC\(hyuser until a primitive requesting transmission is issued. These primitives,
and their relation with operation handling primitives, are considered
now.
.bp
.RT
.sp 1P
.LP
3.1
\fIGrouping of components in a message\fR
.sp 9p
.RT
.PP
The effect of TC\(hyuser issuing a component handling primitive
(unless this primitive has local effect only), is to build a \fBcomponent\fR
to be included in a \fBmessage\fR . The message is not transmitted until
the TC\(hyuser
requests it.
.PP
Note that a component may also be generated as a result of a TCAP
reject: in this case this component is put in the next message for the
dialogue unless it is aborted.
.PP
Provided that the maximum size of a message is not exceeded, several components
can be grouped and sent to the remote end as a single message,
thereby saving transmission overhead. This is done under control of the
TC\(hyuser, which explicitly specifies when it wants (a) component(s) to be
sent.
.PP
Example E3, as given in Table\ 11/Q.775, shows the beginning of a
dialogue with a network service centre where a switch requests instructions
(operation\ 1) and receives a request to connect the call to a given destination
address, and a request to send information (e.g.\ announcement or message
to be displayed) to the calling party. Both components are contained in
a single
message.
.RT
.LP
.sp 1
.ce
\fBH.T. [T11.775]\fR
.ce
TABLE\ 11/Q.775
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(78p) | cw(78p) .
TC USER A TC USER B
_
.T&
lw(78p) | lw(78p) .
{
TC\(hyINVOKE req
(1, Provide\(hyInstructions, Class = 1)
TC\(hyBEGIN req
(control parameters)
}
_
.T&
lw(78p) | lw(78p) .
{
TC\(hyBEGIN ind
(control parameters)
TC\(hyINVOKE ind
(1, Provide\(hyinstructions)
TC\(hyINVOKE req
(2, 1, Connect\(hyCall)
TC\(hyRESULT\(hyL req
(1, Send\(hyInfo)
TC\(hyCONTINUE req
(control parameters)
}
_
.T&
lw(78p) | lw(78p) .
{
TC\(hyCONTINUE ind
(control parameters)
TC\(hyINVOKE ind
(2, 1, Connect\(hyCall)
TC\(hyRESULT\(hyL ind
(1, Send\(hyInfo)
}
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 11/Q.775 [T11.775], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 1
.bp
.PP
TC\(hyBEGIN and TC\(hyCONTINUE are transmission primitives described in
\(sc\ 3.2 below.
.PP
There may be one transmission primitive for each component, but the
separation of primitives allows the grouping of components within a message.
In addition, the information contained in the parameters of the transmission
primitives (e.g.\ addressing information) applies to all the components
included in the message.
.PP
At the originating side, the primitive requesting transmission appears
after a component handling primitive; this indicates that transmission
of the preceeding components has to take place immediately; it avoids indicating
specific components to be transmitted with a given transmission primitive,
and allows transmission primitives without any associated component.
.PP
At the destination side, the primitive requesting transmission appears
first: it contains control information which is necessary for TCAP to deliver
each of the components (if any) in the message; the last component of the
message is indicated to the TC\(hyuser by the \*QLast Component\*U parameter.
The
components are delivered to the destination TC\(hyuser in the same order
as they were passed to TCAP by the originating TC\(hyuser.
.RT
.sp 1P
.LP
3.2
\fIDialogue handling facilities\fR
.sp 9p
.RT
.PP
When two TC\(hyusers co\(hyoperate in an application, more than one
operation invocation is generally required. The resulting flow of components
has to be identified so that:
.RT
.LP
1)
components of the same flow can be related
.LP
2)
flows corresponding to several instances of the same
application can be identified and allowed to run in parallel.
.PP
Each such flow is identified, for the TC\(hyuser, by a dialogue and a corresponding
Dialogue ID\ parameter. The dialogue handling facility provided
for this purpose is the structured dialogue.
.PP
When only a single message is required to complete a distributed
application, the Unidirectional message of the unstructured dialogue may be
used. The originator does not expect a report of the outcome of the operation
(i.e.\ may only invoke class\ 4 operations), but may receive a report of
a
protocol error if one occurs.
.RT
.sp 2P
.LP
3.2.1
\fIStructured dialogue\fR
.sp 1P
.RT
.sp 1P
.LP
3.2.1.1
\fIGeneral\fR
.sp 9p
.RT
.PP
The use of dialogues allows several flows of components to co\(hyexist
between two TC\(hyusers. The Dialogue ID\ parameter is used in both operation
handling and transmission (dialogue) handling primitives to determine which
component(s) pertain(s) to which dialogue.
.PP
The Dialogue ID parameter is represented (by convention) by the first parameter
in these primitives, starting with letter\ D. Each TC\(hyuser has its own
reference for a given dialogue. Local references (those used on the interface)
are represented here; mapping of these local references onto protocol
references included in messages is done by TCAP.
.PP
Three primitives have been defined for handling dialogues under normal
circumstances; they indicate dialogue begin (TC\(hyBEGIN), continuation
(TC\(hyCONTINUE) or end (TC\(hyEND). Each of these primitives may be used
to request transmission of 0, 1 or several components; these components
may contain
information relating to one or several operations.
.bp
.PP
Table 12/Q.775 illustrates a possible sequence for example E2, where the
test request starts the dialogue, which ends when the test result has been
sent.
.RT
.ce
\fBH.T. [T12.775]\fR
.ce
TABLE\ 12/Q.775
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(78p) | cw(78p) .
TC USER A TC USER B
_
.T&
lw(78p) | lw(78p) .
{
TC\(hyINVOKE req
(D1, 1, Test, Class = 1)
TC\(hyBEGIN req
(D1, Address)
}
_
.T&
lw(78p) | lw(78p) .
{
TC\(hyBEGIN ind
(D2, Address)
TC\(hyINVOKE ind
(D2, 1, Test)
TC\(hyINVOKE req
(D2, 2, 1, Option\(hyselection, Class = 1)
TC\(hyCONTINUE req
(D2)
}
_
.T&
lw(78p) | lw(78p) .
{
TC\(hyCONTINUE ind
(D1)
TC\(hyINVOKE ind
(D1, 2, 1, Option\(hyselection)
TC\(hyRESULT\(hyL req
(D1, 2, Options)
TC\(hyCONTINUE\(hyreq
(D1)
TC\(hyEND ind
(D1, normal)
TC\(hyRESULT\(hyL ind
(D1, 1, Test\(hyresult)
} {
.
TC\(hyCONTINUE ind
(D2)
TC\(hyRESULT\(hyL ind
(D2, 2, Options)
TC\(hyRESULT\(hyL req
(D2, 1, Test\(hyresult)
TC\(hyEND req
(D2)
}
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 12/Q.775 [T12.775], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.PP
Any grouping of components is allowed in the messages of a
dialogue: TCAP does not check, for instance, that a message terminating a
dialogue does not include operation invocations of class\ 1. Full\(hyduplex
exchange of components is assumed: if a TC\(hyuser wants to introduce some
restrictions, e.g.\ working in a synchronous mode as defined in ROSE, it
would have to introduce the necessary procedures itself.
.sp 1P
.LP
3.2.1.2
\fIExchange of messages\fR
.sp 9p
.RT
.PP
Transmission of messages is accomplished with the quality of
service of the underlying layer services: no flow control or error recovery
mechanisms are provided by TCAP.
.RT
.LP
\(em
The first dialogue handling primitive of a dialogue must
indicate dialogue begin (TC\(hyBEGIN). Further messages must not be sent
from the side originating the dialogue until a message is received in the
backward
direction, indicating dialogue continuation.
.LP
\(em
If a TC\(hyuser tries to send a large number of messages in a
short amount of time, no flow control mechanism in TCAP will prevent it.
.LP
\(em
SCCP class 1 in\(hysequence delivery can be requested as an
option, indicated by the Quality of Service parameter. Note that this option
may not be available end to end when interworking with a network which
does not provide it.
.sp 1P
.LP
3.2.1.3
\fIDialogue end\fR
.sp 9p
.RT
.PP
TCAP places no restriction on the ability for a TC\(hyuser to request dialogue
end. It follows that messages may be lost if no precautions are taken in
the application on when the dialogue may end. In particular, if the
application protocol allows both TC\(hyusers to issue TC\(hyEND primitives
at about the same time, and if these primitives trigger transmission of
components, it is likely that some (if not all) of these components will
not be delivered to their respective destination TC\(hyusers.
.PP
It is up to the application to define, if necessary, its own rules
concerning the right to end a dialogue: TCAP will not check them. Any message
received for a terminated dialogue is discarded if it requests dialogue
end,
and otherwise causes the dialogue to be aborted at the remote entity.
.PP
The differences between the three ways of ending a dialogue are as
follows.
.RT
.sp 1P
.LP
\fIPrearranged end\fR
.sp 9p
.RT
.PP
A typical application is the access to a distributed database,
where the requesting user (TC\(hyuser\ A) does not know where the information
it
seeks is located. TC\(hyuser\ A broadcasts a request to each location which
might have the information required, and will eventually receive a response
from the TC\(hyuser which holds this information. Prearranged end avoids
messages from the other destinations saying: \*QI do not have this information\*U.
Only the
responding destination may continue the dialogue (if so wished); all other
destination will, by convention, end the dialogue locally; the originator of
the requests will also end the dialogues with the non\(hyresponding destinations
locally, when it receives the response to its request. Note that the convention
is between applications: TCAP does not check that it is respected, nor
is it
indicated in the TCAP protocol.
.PP
Example E4 in Table 13/Q.775 illustrates this situation, with two
destinations B1 and B2; two dialogues (D1, D2) and (D3, D4) are started; B1
happens to own the requested information, and decides to continue the
dialogue.
.bp
.RT
.ce
\fBH.T. [T13.775]\fR
.ce
TABLE\ 13/Q.775
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(80p) | cw(74p) | cw(74p) .
TC USER A TC USER B1 TC USER B2
_
.T&
lw(80p) | lw(74p) | lw(74p) .
{
TC\(hyINVOKE req
(D1, 1, Question)
TC\(hyBEGIN req
(D1, Address)
TC\(hyINVOKE req
(D3, 1, Question)
TC\(hyBEGIN req
(D3, Address)
TC\(hyCONTINUE ind
(D1)
TC\(hyRESULT\(hyL ind
(D1, 1, Response)
\ D1 goes on
\ D3 ends locally
TC\(hyEND req
(D3, local)
} {
.
TC\(hyBEGIN ind
(D2, Address)
TC\(hyINVOKE ind
(D2, 1, Question)
TC\(hyRESULT\(hyL req
(D2, 1, Response)
TC\(hyCONTINUE req
(D2)
......
} {
.
TC\(hyBEGIN ind
(D4, Address)
TC\(hyINVOKE ind
(D4, 1, Question)
B2 does not have the information:
TC\(hyEND req
(D4, local)
}
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 13/Q.775 [T13.775], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 2
.PP
Prearranged end may also be used when a TC\(hyuser wants to send
information, and does not expect a reply of any kind afterwards.
.sp 1P
.LP
\fIBasic end\fR
.sp 9p
.RT
.PP
When a TC\(hyuser issues the TC\(hyEND request primitive, it causes
transmission of any pending components to the remote end. TCAP does not
check that all operation invocations have received a response when dialogue
end is
requested: no notification is given to the TC\(hyuser that any pending
operation invocations have not received a final result.
.PP
At the receiving end, the dialogue is considered terminated when all the
components received within the message indicating the end have been
delivered to the TC\(hyuser.
.bp
.PP
Example: the dialogue ends when the test in example E1,
Table\ 14/Q.775, receives a response.
.RT
.ce
\fBH.T. [T14.775]\fR
.ce
TABLE\ 14/Q.775
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(78p) | cw(78p) .
TC USER A TC USER B
_
.T&
lw(78p) | lw(78p) .
{
......
TC\(hyEND ind
(D1)
TC\(hyRESULT\(hyNL ind
(D1, 1, P1)
TC\(hyRESULT\(hyNL ind
(D1, 1, P2)
TC\(hyRESULT\(hyL ind
(D1, 1, P3)
End of dialogue for A
} {
......
TC\(hyRESULT\(hyNL req
(D2, 1, P1)
TC\(hyRESULT\(hyNL req
(D2, 1, P2)
TC\(hyRESULT\(hyL req
(D2, 1, P3)
TC\(hyEND req
(D2, normal)
End of dialogue for B
}
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 14/Q.775 [T14.775], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
\fIAbort by the TC\(hyuser\fR
.sp 9p
.RT
.PP
The abort facility allows the TC\(hyuser to stop the dialogue at any time.
A typical case is when the user abandons the service. The main
differences between this and normal ending are:
.RT
.LP
\(em
any components for which transmission is pending are not sent to the
peer entity;
.LP
\(em
peer\(hyto\(hypeer information can be indicated at the time the
abort is issued, and this is delivered to the remote TC\(hyuser.
.PP
The sequence given in Table\ 15/Q.775 shows a user abandonment in example E2.
.sp 1P
.LP
3.2.1.4
\fIMessage\(hyrelated abnormal situations\fR
.sp 9p
.RT
.PP
These are considered independently from the effects of such events in the
Component sub\(hylayer.
.RT
.sp 1P
.LP
\fIMessage loss\fR
.sp 9p
.RT
.PP
TCAP provides no protection against message loss. Three cases are identified:
.RT
.LP
1)
the message begins a new dialogue: the dialogue will exist
at the originating side only, and no message will be allowed in
either direction. Eventually, an implementation\(hydependent
mechanism of TCAP ends the dialogue at the originating end;
.LP
2)
the message continues an existing dialogue: loss is not
detected. TCAP will react (or not) to the loss of included
components as indicated in \(sc\ 2.4.1 above;
.LP
3)
the message ends a dialogue: TCAP will eventually react if
this message contained a response to a class\ 1 operation:
otherwise an implementation\(hydependent mechanism may end the
dialogue at the destination end.
.bp
.LP
.ce
\fBH.T. [T15.775]\fR
.ce
TABLE\ 15/Q.775
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(78p) | cw(78p) .
TC USER A TC USER B
_
.T&
lw(78p) | lw(78p) .
{
TC\(hyINVOKE req
(D1, 1, Test, Class = 1)
TC\(hyBEGIN req
(D1, Address)
}
_
.T&
lw(78p) | lw(78p) .
{
TC\(hyBEGIN ind
(D2, Address)
TC\(hyINVOKE ind
(D2, 1, Test)
TC\(hyINVOKE req
(D2, 2, 1, Option\(hyselection, Class = 1)
TC\(hyCONTINUE req
(D2)
}
_
.T&
lw(78p) | lw(78p) .
{
TC\(hyCONTINUE ind
(D1)
TC\(hyINVOKE ind
(D1, 2, 1, Option\(hyselection)
User abandon:
TC\(hyU\(hyABORT req
(D1, Cause)
}
_
.T&
lw(78p) | lw(78p) .
{
TC\(hyU\(hyABORT ind
(D2, Cause)
}
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 15/Q.775 [T15.775], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 2
.sp 1P
.LP
\fIMessage duplication\fR
.sp 9p
.RT
.PP
Duplication of a BEGIN message causes two transactions to be
opened, as indicated below: each of these transactions has its own local\ ID,
and the same destination ID. The TC\(hyuser eventually detects that something
is wrong, and both dialogues are aborted.
.bp
.PP
The sequence given in Table 16/Q.775 illustrates a duplication of the BEGIN
message in Example\ E2.
.RT
.ce
\fBH.T. [T16.775]\fR
.ce
TABLE\ 16/Q.775
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(78p) | cw(78p) .
TC USER A TC USER B
_
.T&
lw(78p) | lw(78p) .
{
TC\(hyINVOKE req
(D1, 1, Test, Class = 1)
TC\(hyBEGIN req
(D1, Address)
}
_
.T&
lw(78p) | lw(78p) .
{
.
TC\(hyCONTINUE ind
(D1)
TC\(hyINVOKE ind
(D1, 2, 1, Option\(hyselect)
} {
TC\(hyBEGIN ind
(D2, Address)
TC\(hyINVOKE ind
(D2, 1, Test)
Duplicated BEGIN:
TC\(hyBEGIN ind
(D3, Address)
TC\(hyINVOKE ind
(D3, 1, Test)
Response to the first Begin
TC\(hyINVOKE req
(D2, 2, 1, Option\(hyselect, Class = 1)
TC\(hyCONTINUE req
(D2)
Response to the second Begin
TC\(hyINVOKE ind
(D3, 2, 1, Option\(hyselect, Class = 1)
TC\(hyCONTINUE req
(D3)
}
_
.T&
lw(78p) | lw(78p) .
{
TC\(hyCONTINUE ind
(D1)
TC\(hyINVOKE ind
(D1, 2, 1, Option\(hyselect)
TC\(hyuser considers that this invocation is abnormal, and may reject it, or
abort one of the dialogues:
TC\(hyU\(hyABORT req
(D1, Cause)
}
_
.T&
lw(78p) | lw(78p) .
{
TC\(hyU\(hyABORT ind
(D3, Cause)
}
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 16/Q.775 [T16.775], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.PP
At that moment, there is still one dialogue (with local ID D2) at TC\(hyuser
B's side, but no dialogue at A's side. TC\(hyuser\ B will receive an
indication from TCAP when operation\ 2 of dialogue D2 timeouts with no reply
(TC\(hyL\(hyCANCEL ind), and may then decide to abort D2. Note that the
situation
would be more difficult to detect, had TC\(hyuser\ B not invoked a class 1
operation.
.PP
Duplication of a CONTINUE message is not detected by TCAP.
.PP
When an END message is duplicated, the second message is received with
an ID which does not correspond to an active dialogue: TCAP reacts by
discarding the duplicate message.
.RT
.sp 1P
.LP
\fIMissequencing of messages\fR
.sp 9p
.RT
.PP
When the missequenced messages involve neither the beginning, nor the end
of a dialogue, missequencing is not detected by TCAP, and may result in
component missequencing, to which TCAP would react as indicated in \(sc\
2.5.3
above.
.PP
When a message indicating dialogue continuation arrives after a
message indicating the end of the same dialogue, it is not delivered, and
causes TCAP to abort the dialogue; the TC\(hyuser will probably detect the loss
when receiving a premature dialogue end indication. If the application
needs to recover from this case, a new dialogue should be started.
.RT
.sp 1P
.LP
\fIMessage corruption\fR
.sp 9p
.RT
.PP
When receiving a corrupted message, TCAP reacts as indicated in
Recommendation\ Q.774.
.PP
Table 17/Q.775 shows the sequence of primitives when TCAP decides to abort
the dialogue after receiving a corrupted message in example\ E2.
.RT
.ce
\fBH.T. [T17.775]\fR
.ce
TABLE\ 17/Q.775
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(78p) | cw(78p) .
TC USER A TC USER B
_
.T&
lw(78p) | lw(78p) .
{
TC\(hyINVOKE req
(D1, 1, Test, Class = 1)
TC\(hyBEGIN req
(D1, Address)
}
_
.T&
lw(78p) | lw(78p) .
{
TC\(hyBEGIN ind
(D2, Address)
TC\(hyINVOKE ind
(D2, 1, Test)
TC\(hyINVOKE req
(D2, 2, 1, Option\(hyselect, Class = 1)
TC\(hyCONTINUE req
(D2)
}
_
.T&
lw(78p) | lw(78p) .
{
Corrupted message:
TC\(hyABORT ind
(D1, Cause)
} . TC\(hyABORT ind (D2, Cause)
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 17/Q.775 [T17.775], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
3.2.1.5
\fIRelations between dialogue handling and operation handling\fR
.sp 9p
.RT
.PP
Depending on the moment when the dialogue end is requested, the
TCAP facilities associated with an operation will be available until the
end of the dialogue, or not. The following gives some guidelines on when
dialogue end can be requested; if these are not respected, TCAP will not
refuse the request for dialogue end.
.PP
The problems that may result from the collision of messages requesting
dialogue end have been considered above.
.PP
Normal end should not be requested when:
.RT
.LP
\(em
there are operation invocations pending for the dialogue;
.LP
\(em
the application protocol anticipates that replies being
transmitted with the termination request could be rejected.
.PP
In addition, a request for dialogue end must not trigger
transmission of operation invocations, since no reply could be received for
these operations.
.PP
Many applications might not define recovery scenarios in response to a
rejected reply. This legitimises the transmission of replies or of class\
4
operations in a message indicating dialogue end. The other applications
should either use the connection\(hyoriented network service approach,
or end the
dialogue with a message containing no component, that would be sent only
when a reject indication can no longer be received.
.RT
.sp 1P
.LP
3.2.2
\fIUnstructured dialogue\fR
.sp 9p
.RT
.PP
A Unidirectional message will contain either only class\ 4 operation invocations
or reports of protocol errors in such invocations. Multiple
components can be transmitted in a Unidirectional message provided that the
maximum size of a message is not exceeded.
.RT
.sp 2P
.LP
\fB4\fR \fBApplication service elements\fR \fBand\fR
\fBapplication\fR
\fBentities\fR
.sp 1P
.RT
.sp 1P
.LP
4.1
\fIIntroduction\fR
.sp 9p
.RT
.PP
This material supplements preceding material providing guidelines on the
usage of TC by describing what needs to be included in an Application
Entity (AE) specification. This material is based on CCITT
Recommendations\ X.219 and X.229 and requires further study.
.PP
CCITT Recommendation Q.700, \(sc\ 3.2.3.6, describes how Application
Service Elements (ASEs) and Application Entities (AEs) are structured and
how an AE is addressed in Signalling System No.\ 7.
.PP
This section illustrates that architecture, considering the functional
decomposition of an application, and describes how AEs, ASEs, operations
and
errors should be defined.
.RT
.sp 1P
.LP
4.2
\fIDecomposition of\fR
\fIfunctionality\fR
.sp 9p
.RT
.PP
Application process functions communicate through one or more
Application Entities (AEs). The combination of two peer AEs plus their
interaction is called the Application Context. An AE consists of communications
for one or more functions of an application. Each communications function
forms an ASE which is an integrated set of actions and may be used in more
than an
AE. TCAP is itself an ASE which is used by other ASEs as well as being
common to AEs (see \(sc\ 3.2.3.6/Q.700). An ASE identifies one or more
operations and
specifies how those operations are used; that is, which peer entity may
invoke which operations, and in what order. Operations may be selected
from one or
more libraries.
.PP
An ASE provides a service to the user of the ASE. An ASE is used by
two complementary AEs: the consumer of the service and the supplier of the
service. The consumer of the service is the end that initiates the AE to AE
communication. An ASE user is thus generally asymmetric.
.bp
.PP
Within an ASE, the mechanism for providing the ASE service is the
invocation of operations by the service requestor on the service provider.
Each operation provides a part of the service in an inherently asymmetric
manner
since it is invoked by one AE and executed by the peer AE. An ASE generally
includes more than one operation. An ASE user is, in general, not limited to
either invoking or performing operations, but may both invoke or perform the
same or different operations. Also, an ASE user may exist at a pair of nodes
such that either node may request the same service from the other node. That
is, the AEs at the nodes may be symmetric, both invoking and executing the
same operations.
.PP
\fINote\fR \ \(em\ Primitives which provide a standard service interface
for the access of ASEs within AEs are for further study.
.PP
Figure 3/Q.775 illustrates the decomposition of this functionality and
provides examples.
.RT
.LP
.sp 2
.rs
.sp 21P
.ad r
\fBFigure 3/Q.775, (N), p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 2
.sp 1P
.LP
4.3
\fIHow to specify an AE\fR
.sp 9p
.RT
.PP
CCITT Recommendation Q.700, \(sc\ 3.2.3.6, describes how two Signalling
System No.\ 7 Application Processes communicate via Application Entities,
and
also the structure of an AE.
.PP
The application designer should provide a definition for each type of AE.
It should contain:
.RT
.LP
\(em
A general description of the services supported by the
combination of the two peer AEs and communicating by a dialogue.
(In Recommendation\ X.229 terminology, this corresponds to the
\*QApplication Context\*U).
.LP
\(em
A definition of the complete application protcol between the
peer AEs by:
.LP
\(em
identifying each ASE constituting the AE, and
.LP
\(em
indicating which of the peer AEs initiates the
service.
.LP
\(em
Any special constraints to ensure that peer AEs with
different versions are compatible.
.bp
.PP
A formal specification of the application context using the
Recommendation\ X.229 APPLICATION\(hyCONTEXT macro is for further study.
.PP
Since each AE constitutes a single coding domain for operation and
error code values (addressed by SCCP subsystem number in a connectionless
network service environment), each operation or error code value must be
unique within the AE (see \(sc\ 4.5).
.RT
.sp 1P
.LP
4.4
\fIHow to specify an ASE\fR
.sp 9p
.RT
.PP
The definition of an ASE is part of the stage 3 of the service
description methodology, as defined by Recommendation\ I.220.
.PP
The ASE description should provide:
.RT
.LP
\(em
A general description of the ASE and its procedures.
.LP
\(em
The information flows between the entities which are
communicating to support the service, based on stage\ 2, with additions and
enhancements that are needed as part of the protocol design.
.LP
\(em
A detailed description of the ASE protocol. This includes the sequence
in which operations may be invoked, and the reaction to abnormal
situations. The definition should include how protocol version interwork.
Dialogue begin, continuation and end should be specified. This section
should describe the interaction between the ASE and the TCAP component
sub\(hylayer
expressed in terms of the primitive interface.
.LP
\(em
SDL diagrams.
.PP
Recommendation X.229 (ROSE) defines an APPLICATION\(hySERVICE\(hyELEMENT
macro which may be used to specify an ASE formally. It identifies which
operations are contained in the AE and how they are invoked. The use of this
macro in Signalling System No.\ 7 is for further study.
.sp 2P
.LP
4.5
\fIHow to specify operations and errors\fR
.sp 1P
.RT
.sp 1P
.LP
4.5.1
\fIInformation needed to specify operations and errors\fR
.sp 9p
.RT
.PP
To specify an operation, the following items must be
defined:
.RT
.LP
\(em
The operation name.
.LP
\(em
The operation code. This may be local or global. See
\(sc\ 4.5.2.
.LP
\(em
The operation class. A value in the range 1 to 4 as defined in \(sc\ 2.2.1.
.LP
\(em
The parameters accompanying the operation invocation (input parameters).
Further essential information to supplement that provided in the parameters
with the original invocation may be requested using linked
operations.
.LP
\(em
The parameters that may be returned as the result of a
successful outcome (Return Result), whenever the operation reports success
(possitive output parameters). The way these parameters are actually passed
(in a single component or several) is no part of the operation description.
.LP
\(em
The error codes and associated parameters that may be
returned as the result of an unsuccessful outcome (Return Error) of the
operation execution, whenever this operation reports failure (negative
output parameters). An error code must be present when reporting failure,
and all the possible values be defined as part of the operation description.
.LP
\(em
The allowed linked operations (see \(sc\ 2.2.2).
.LP
\(em
The timer value for completion of the operation.
.PP
The operation description consists of a Table indicating the eight items
above, together with a short prose description of what the operation
does. A formal definition using Annex\ A/Q.773 OPERATION and ERROR macros
should also be included to unambiguously indicate which parameters are
mandatory,
which are optional with default values as applicable, and which individual,
sets or sequences of parameters are legal as input, positive output, and
negative output. The OPERATION and ERROR type (macro) definitions are exported
from the TCAP definitions (Annex\ A/Q.773) and need to be imported into
the ASE being defined in order to define operations and errors.
.bp
.PP
The syntax of the OPERATION MACRO (reproduced from Annex\ A/Q.773) is as
follows:
.RT
.sp 1P
.LP
OPERATION MACRO ::=
.sp 9p
.RT
.LP
BEGIN
.LP
TYPE NOTATION ::=
Parameter Result Errors Linked Operations
.LP
VALUE NOTATION ::=
valu { ALUE CHOIC {
value(VALUE CHOICE
localValue INTEGER,
value(VALUE CHOICE
globalValue OBJECT IDENTIFIER\ }
.sp 1P
.LP
Parameter ::=
\*QPARAMETER\*U Named Type\ | empty
.sp 9p
.RT
.LP
Result ::=
\*QRESULT\*U ResultType\ | empty
.LP
ResultType ::=
NamedType\ | empty
.LP
Errors ::=
\*QERRORS\*U \* { *UErrorNames\* } *U\ | empty
.LP
LinkedOperations ::=
\*QLINKED\*U \* { *ULinkedOperationNames\* } *U\ | empty
.LP
ErrorNames ::=
ErrorList\ | empty
.LP
ErrorList ::=
Error\ | ErrorList \*Q,\*U Error
.LP
Error ::=
value (ERROR)\ \(em\(em\ \fIshall reference an error value\fR | type\
\(em\(em\ \fIshall reference an error type if no error value\fR
| type\
\(em\(em\ \fIis specified\fR
.sp 1P
.LP
LinkedOperationNames\ ::=
OperationList\ | empty
.sp 9p
.RT
.LP
OperationList ::=
Operation\ | OperationList \*Q,\*U Operation
.LP
Operation ::=
value (OPERATION)\ \(em\(em\ \fIshall reference an operation value\fR
| type\ \(em\(em\ \fIshall reference an operation type if no error value\fR
| type\
\(em\(em\ \fIis specified\fR
.sp 1P
.LP
NamedType ::=
identifier type\ | type
.sp 9p
.RT
.LP
END
.sp 1P
.LP
ERROR MACRO ::=
.sp 9p
.RT
.LP
BEGIN
.LP
TYPE NOTATION ::=
Parameter
.LP
VALUE NOTATION ::=
value (VALUE CHOIC {
valu { ALUE CHOICE
localValue INTEGER,
valu { ALUE CHOICE
globalValue OBJECT IDENTIFIER\ }
.sp 1P
.LP
Parameter ::=
\*QPARAMETER\*U NamedType\ | empty
.sp 9p
.RT
.LP
NamedType ::=
identifier type\ | type
.LP
END
.PP
The use of local and global values is explained in \(sc\ 4.5.2.
.PP
As an example, the CUGCheck2 operation, which is used to check whether
an incoming call is compatible with the CUG characteristics of the called
party, is described here in both (abbreviated) formal notation, and in
the form of a table.
.RT
.sp 1P
.LP
4.5.2
\fIExample of operation description\fR
.sp 9p
.RT
.PP
(\fINote\fR \ \(em\ Arbitrary section numbers are used in this
example.)
.bp
.RT
.sp 2P
.LP
3.4.3.1
\fIDescription of operations\fR
.sp 1P
.RT
.sp 1P
.LP
3.4.3.1.1
\fICUG check 1\fR
.sp 9p
.RT
.PP
This operation is used between the originating exchange of a call and a
dedicated point for CUG validation check of the calling user.
.RT
.sp 1P
.LP
3.4.3.1.2
\fICUG check 2\fR
.sp 9p
.RT
.PP
This operation is used between the terminating exchange of a call and a
dedicated point for CUG validation check of the called user.
.RT
.sp 2P
.LP
3.4.3.2
\fIParameters of operations and outcomes\fR
.sp 1P
.RT
.sp 1P
.LP
3.4.3.2.1
\fICUG Check 1\fR
.sp 9p
.RT
.LP
.sp 3
.ce
\fBH.T. [T18.775]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(72p) | cw(72p) | cw(30p) | cw(54p) .
CUG Check 1 Timer = x sec Class = 1 Code = 00000001
_
.T&
lw(144p) | cw(30p) | cw(54p) .
Parameters with Invoke Opt/Man Reference
_
.T&
lw(144p) | cw(30p) | cw(54p) .
{
CallingUserIndex
CUGCallIndicator
CallingPartyNumber
} O M M 3.4.3.3.1 3.4.3.3.2 3.4.3.3.3
_
.T&
lw(144p) | cw(30p) | cw(54p) .
Parameters with Return Result
_
.T&
lw(144p) | cw(30p) | cw(54p) .
{
CUGInterlockCode
CUGCallIndicator
} O M 3.4.3.3.5 3.4.3.3.2
_
.T&
lw(144p) | cw(30p) | cw(54p) .
Linked Operations
_
.T&
lw(144p) | cw(30p) | cw(54p) .
Not applicable
_
.T&
lw(144p) | cw(30p) | cw(54p) .
Errors
_
.T&
lw(144p) | cw(30p) | cw(54p) .
UnsuccessfulCheck 3.4.3.3.7
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau du \(sc\ 3.4.3.2.1, [T18.775], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 3
.LP
cUGCheck1\ \ \ OPERATION
PARAMETER
SEQUENC { | allingUserIndex OPTIONAL,
cUGCallIndicator,
SEQUENC { |
callingPartyNumber\ }
RESULT
SEQUENC { | UGInterlockCode OPTIONAL,
cUGCallIndicator\ }
ERRORS
SEQUENCE
{ | nsuccessfulCheck\ }
::= 1
.bp
.sp 1P
.LP
3.4.3.2.2
\fICUG check 2\fR
.sp 9p
.RT
.ce
\fBH.T. [T19.775]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(72p) | cw(72p) | cw(30p) | cw(54p) .
CUG Check 2 Timer = x sec Class = 1 Code = 00000010
_
.T&
lw(144p) | cw(30p) | cw(54p) .
Parameters with Invoke Opt/Man Reference
_
.T&
lw(144p) | cw(30p) | cw(54p) .
{
CUGInterlockCode
CUGCallIndicator
CalledPartyNumber
} M M M 3.4.3.3.5 3.4.3.3.2 3.4.3.3.4
_
.T&
lw(144p) | cw(30p) | cw(54p) .
Parameters with Return Result
_
.T&
lw(144p) | cw(30p) | cw(54p) .
{
CalledUserIndex
CUGCallIndicator
} O M 3.4.3.3.6 3.4.3.3.2
_
.T&
lw(144p) | cw(30p) | cw(54p) .
Linked Operations
_
.T&
lw(144p) | cw(30p) | cw(54p) .
Not applicable
_
.T&
lw(144p) | cw(30p) | cw(54p) .
Errors
_
.T&
lw(144p) | cw(30p) | cw(54p) .
UnsuccessfulCheck 3.4.3.3.7
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau du \(sc\ 3.4.3.2.2, [T19.775], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
cUGCheck 2\ \ \ OPERATION
PARAMETER
SEQUENC { | UGInterlockCode, cUGCallIndicator,
SEQUENC { |
calledPartyNumber\ }
RESULT
SEQUENC { | alledUserIndex OPTIONAL, cUGCallIndicator\ }
ERRORS
SEQUENCE
{ | nsuccessfulCheck\ }
::= 2
.sp 1P
.LP
3.4.3.3
\fIParameter coding\fR
.sp 9p
.RT
.LP
3.4.3.3.1\ \ The CallingUserIndex is the local index at the calling user to
identify a particular CUG he belongs to.
.ce
\fBH.T. [T20.775]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(144p) | cw(72p) .
CallingUserIndex Code = 10000001
_
.T&
lw(72p) | lw(144p) .
Contents Meaning
_
.T&
lw(72p) | lw(144p) .
IA5 Character String {
One IA5 character represents one digit of the CUG index
value
}
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau du \(sc\ 3.4.3.3, [T20.775], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
callingUserIndex ::=
[1]\ IMPLICIT LocalIndex
LocalIndex ::=
IA5\ STRING
\(em\(em\ \fIThe maximum number of digits is four.\fR .bp
.sp 1P
.LP
3.4.3.3.2\ \ The CUGCallIndicator indicates whether the call is requested
or designated as a CUG call and whether outgoing access is requested or
allowed.
.sp 9p
.RT
.ce
\fBH.T. [T21.775]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(144p) | cw(72p) .
CUGCallIndicator Code = 10000010
_
.T&
cw(72p) | lw(144p) .
Contents Meaning
_
.T&
cw(72p) | lw(144p) .
{
00000000
00000001
00000010
00000011
} {
Non\(hyCUG call
Non\(hyCUG call
CUG call with outgoing access
CUG call without outgoing access
}
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau du \(sc\ 3.4.3.3.2, [T21.775], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
cUGCallIndicator ::=
[2]\ IMPLICIT CallIndicator
.LP
CallIndicator ::=
INTEGE {
nonCUGCall (0),
nonCUGCall (1),
outgoingAccessAllowedCUGCall (2),
outgoingAccessNotAllowedCUGCall (3)\ }
.sp 1P
.LP
3.4.3.3.3\ \ The CallingPartyNumber is the network (e.g.\ E.164) number
of the calling party. It is expressed in the same manner as the ISUP Calling
party
number in \(sc\ 3.7 of Recommendation\ Q.763. The code of this parameter is
\*Q10000011\*U.
.sp 9p
.RT
.ce
\fBH.T. [T22.775]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(144p) | cw(72p) .
CallingPartyNumber Code = 10000011
_
.T&
lw(72p) | lw(144p) .
Contents Meaning
_
.T&
lw(216p) .
{
\(em | (em encoded per \(sc 3.7/Q.763
}
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau du \(sc\ 3.4.3.3.3, [T22.775], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
callingPartyNumber ::=\ [3]\ IMPLICIT OCTET STRING
\(em\(em\ \fIcontents encoded per \(sc\ 3.7/Q.793\fR
.sp 1P
.LP
3.4.3.3.4\ \ The CalledPartyNumber is the network (e.g.\ E.164) number
of the called party. It is expressed in the same manner as the ISUP Called
party
number in \(sc\ 3.6 of Recommendation\ Q.763. The code of this parameter is
\*Q10000100\*U.
.sp 9p
.RT
.ce
\fBH.T. [T23.775]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(144p) | cw(72p) .
CalledPartyNumber Code = 10000100
_
.T&
lw(72p) | lw(144p) .
Contents Meaning
_
.T&
lw(216p) .
{
\(em | (em encoded per \(sc 3.6/Q.763
}
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau du \(sc\ 3.4.3.3.4, [T23.775], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
calledPartyNumber ::=\ [4]\ IMPLICIT OCTET STRING
\(em\(em\ \fIcontents encoded per \(sc\ 3.6/Q.793\fR .bp
.sp 1P
.LP
3.4.3.3.5\ \ The CUGInterlockCode is the code to uniquely identify a CUG
inside the network. It is expressed in the same manner as the ISUP CUG
interlock code in \(sc\ 3.13 of Recommendation\ Q.763. The code of this
parameter is \*Q10000101\*U.
.sp 9p
.RT
.LP
.sp 1
.ce
\fBH.T. [T24.775]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(144p) | cw(72p) .
CUGInterlockCode Code = 10000101
_
.T&
lw(72p) | lw(144p) .
Contents Meaning
_
.T&
lw(216p) .
{
\(em | (em encoded per \(sc 3.13/Q.763
}
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau du \(sc\ 3.4.3.3.5, [T24.775], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 1
.LP
CUGInterlockCode ::=\ [5]\ IMPLICIT OCTET STRING
\(em\(em\ \fIcontents encoded per \(sc\ 3.13/Q.793\fR
.sp 1P
.LP
3.4.3.3.6\ \ The CalledUserIndex is the local index at the called user to
identify a particular CUG he belongs to. Refer to \(sc\ 3.4.3.3.1. The
code of this parameter is \*Q10000110\*U.
.sp 9p
.RT
.LP
.sp 1
.ce
\fBH.T. [T25.775]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(144p) | cw(72p) .
CalledUserIndex Code = 10000110
_
.T&
lw(72p) | lw(144p) .
Contents Meaning
_
.T&
lw(72p) | lw(144p) .
IA5 Character String {
One IA5 character represents one digit of the CUG Index
value
}
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau du \(sc\ 3.4.3.3.6, [T25.775], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 1
.LP
CalledUserIndex ::=\ [6]\ IMPLICIT LocalIndex
.sp 1P
.LP
3.4.3.3.7
\fIErrors\fR
.sp 9p
.RT
.LP
.sp 1
.ce
\fBH.T. [T26.775]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(144p) | cw(72p) .
UnsuccessfulCheck Code = 00000001
_
.T&
lw(144p) | lw(72p) .
Parameters
_
.T&
lw(144p) | lw(72p) .
Cause 3.4.3.3.8
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau du \(sc\ 3.4.3.3.7, [T26.775], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 1
.LP
unsuccessfulCheck
ERROR
PARAMETER
{ | ause\ }
::= 1
.bp
.sp 1P
.LP
3.4.3.3.8\ \ The Cause indicates the reason why the CUG check is
unsuccessful.
.sp 9p
.RT
.ce
\fBH.T. [T27.775]\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(144p) | cw(84p) .
Cause Code = 10000111
_
.T&
lw(84p) | lw(144p) .
Contents binary (decimal) Meaning
_
.T&
lw(84p) | lw(144p) .
00110010 (50) {
Requested facility not subscribed
}
.T&
lw(84p) | lw(144p) .
00110101 (53) {
Outgoing calls barred within CUG
}
.T&
lw(84p) | lw(144p) .
00110111 (55) {
Incoming calls barred within CUG
}
.T&
lw(84p) | lw(144p) .
00111110 (62) {
InconsistencyInDesignatedOutgoingAccessInformationAndSubscriberClass
}
.T&
lw(84p) | lw(144p) .
01010110 (90) Non\(hyexistent CUG
.T&
lw(84p) | lw(144p) .
01010111 (87) Called user not member of CUG
.T&
lw(84p) | lw(144p) .
01011000 (88) Incompatible destination
.T&
lw(84p) | lw(144p) .
10000000 (110) Inconsistency in data
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau du \(sc\ 3.4.3.3.8, [T27.775], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
cause ::=
[7]\ IMPLICIT CauseCode
.LP
CauseCode ::=
INTEGE {
requestedFacilityNotSubscribed (50),
outgoingCallsBarredWithinCUG(53),
incomingCallsBarredWithinCUG(55),
inconsistencyInDesignatedOutgoingAccessInformationAndsubscriberClass(62),
nonExistentCUG(90),
calledUserNotMemberOfCUG(87),
incompatibleDestination(88),
inconsistencyInData(110)\ }
.sp 1P
.LP
4.5.3
\fIAllocation and management of operation and error codes\fR
.sp 9p
.RT
.PP
The simple approach is to provide one module containing the
definition of the operations and errors it uses as a self\(hycontained local
domain.
.PP
Before defining a new operation, the application designer should check
all modules to see whether a similar operation already exists. To avoid
redefining the operation in a number of modules, methods are required which
allow a module to import the definition of the operations it uses from other
modules. If the opertion does not exist, the designer should specify it
locally.
.PP
\fIExample:\fR | Operation code 00000010 has one meaning for ASE1, and
probably a completely different meaning for ASE2; two domains are
involved.
.PP
Note that many domains may be used by one ASE; however, for
simplicity, it is assumed in the following that an ASE uses only one
domain.
.PP
In addition to its local operation, an ASE may need to make use of
operations which are already defined in another domain. There are two methods
for doing so:
.RT
.LP
\(em
import operation and error types from other modules;
.LP
\(em
import operation and error values from other
modules.
.sp 1P
.LP
4.5.3.1
\fIImport of types\fR
.sp 9p
.RT
.PP
The definition of an operation type includes the notational aspects (see
the OPERATION MACRO above), without allocating the code values.
.PP
It may be desirable to import the type of an already existing
operation, however the importing module may want to allocate its own local
codepoint to the imported operation or error. The imported operation or
error becomes a member of the local domain of that module.
.bp
.PP
If two different modules import a given operation by type, its
codepoint in each of the importing local domains is generally
different.
.PP
Importing by type allows a common description of operations.
A module importing by types only uses a single domain (its local
domain), as represented in Figure\ 4/Q.775.
.RT
.LP
.rs
.sp 11P
.ad r
\fBFigure 4/Q.775, (N), p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
4.5.3.2
\fIImport of values\fR
.sp 9p
.RT
.PP
When operation values are imported, the type and the coding are the same
in the exporting and importing ASEs.
.PP
A module importing operations or errors by value makes use
of:
.RT
.LP
\(em
a local domain for its local operations and
.LP
\(em
the exporting domains for its imported operations.
.PP
A global value is required in the second case to avoid ambiguity between
local codepoints and imported codepoints, as represented in
Figure\ 5/Q.77.
.LP
.rs
.sp 12P
.ad r
\fBFigure 5/Q.775, (N), p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
4.6
\fIApplying the concept to service protocols\fR
.sp 9p
.RT
.PP
The first step, before assigning operation codes, is to examine the service
ASEs (each an integrated set of actions) and assign them to AEs. The
extremes are, on one hand, that all service ASEs are assigned to one AE
and, on the other hand, that each AE is composed of only one service ASE.
The likely
case is several groupings of service ASEs.
.PP
Each AE should be identified by a SSN, but not necessarily a fixed SSN
specified in Recommendation\ Q.713. Within an AE, an operation code assignment
scheme is used, so that no two operations can have the same operation
code.
.RT
.LP
.bp
.LP
\fBMONTAGE:\ \fR PAGE 134 = PAGE BLANCHE
.sp 1P
.RT
.LP
.bp
.sp 1P
.ce 1000
\v'3P'
SECTION\ 2
.ce 0
.sp 1P
.ce 1000
\fBTEST\ SPECIFICATION\fR
.ce 0
.sp 1P
.sp 2P
.LP
\fBRecommendation\ Q.780\fR
.RT
.sp 2P
.ce 1000
\fBSIGNALLING\ SYSTEM\ NO.\ 7\ TEST\ SPECIFICATION\fR
.EF '% Fascicle\ VI.9\ \(em\ Rec.\ Q.780''
.OF '''Fascicle\ VI.9\ \(em\ Rec.\ Q.780 %'
.ce 0
.sp 1P
.ce 1000
\fBGENERAL\ DESCRIPTION\fR
.ce 0
.sp 1P
.LP
\fB1\fR \fBGeneral\fR
.sp 1P
.RT
.PP
This Recommendation is an introductory Recommendation to the test specifications
of Signalling System\ No.\ 7. The test specifications are
contained in Recommendations\ Q.781\(hyQ.783. This Recommendation defines
the scope and purpose of the test specification and identifies guidelines
that are either specific to the particular protocol under test, or are
more general. In
addition it identifies functional requirements imposed by the test
specification.
.RT
.sp 2P
.LP
\fB2\fR \fBGeneal principles of test specifications\fR
.sp 1P
.RT
.PP
The test specification aims at testing protocol conformance in a
given implementation. This is independent of a given implementation and does
not generally imply any modification of the signalling point under test.
However, it is recognized that certain tests require capabilities of the
system that are not explicitly defined in the relevant Recommendation,
and these
capabilities may not be present in all implementations. As a consequence,
certain tests may not be possible in all implementations.
.RT
.sp 2P
.LP
\fB3\fR \fBScope of the test specification\fR
.sp 1P
.RT
.PP
The test specification is intended to cover all aspects of
Signalling System\ No.\ 7. However the initial Recommendations cover the
message transfer part\ Q.701\(hyQ.707, and the telephone user part\ Q.721\(hyQ.724.
The test
specification is not a definition of the protocol, this is contained in
Recommendations\ Q.701\(hyQ.707 and Q.721\(hyQ.724 as appropriate.
.RT
.sp 2P
.LP
\fB4\fR \fBField of application\fR
.sp 1P
.RT
.PP
The test specification applies in the international network, and if appropriate
in the national network. In the international network, the actual tests
to be performed will be the subject of appropriate bilateral agreements
beween the two or more Administrations/RPOAs concerned.
.RT
.sp 2P
.LP
\fB5\fR \fBMethod of application\fR
.sp 1P
.RT
.PP
The test specification fulfils the requirements for both validation testing
and compatibility testing. See \(sc\(sc\ 5.1 and 5.2 for an explanation
of
these terms.
.PP
All tests in the test specification are validation tests (VAT), and in
addition those marked with an asterisk are also compatibility tests
(CPT).
.bp
.RT
.sp 1P
.LP
5.1
\fIValidation testing\fR
.sp 9p
.RT
.PP
The function of validation testing is to check that a given
implementation conforms to the relevant CCITT Recommendations of the Signalling
System. These validation tests could apply both in the national and
international networks. The validation test is a pre\(hyrequisite of compatibility
testing (see \(sc\ 5.2) and is performed under the responsibility of each
Administration/RPOA. These tests will generally be performed without the
cooperation of another Administration/RPOA, although this is not precluded
should this arrangement prove convenient. Validation testing will be performed
on a signalling point that is not in service.
.PP
The validation test is performed on one signalling point.
.PP
It is suggested that the validation test, or subset, is repeated when the
implementation is upgraded or modified in any functional way.
.PP
Validation testing may require the use of a simulator to check the
operation of the signalling point under test. The specification of this
simulator is not explicitly covered by these Recommendations although the
general requirements are implicit in the test specification.
.PP
In validation testing, the signalling point under test is called
SP\*QA\*U.
.RT
.sp 1P
.LP
5.2
\fICompatibility testing\fR
.sp 9p
.RT
.PP
The objective of compatibility testing is to check for the correct interworking
of two implementations. To perform compatibility testing the two nodes
involved are interconnected. The specification is written for the
interconnection of two given implementations for the first time. For subsequent
interconnections of the same two implementations a subset of tests may
prove
sufficient. These tests will not only be performed on a new signalling
point, but also on a signalling point already in service.
.PP
Each Recommendation identifies a list of tests that may be suitable
for compatibility testing, but the actual tests to be performed will be
bilaterally agreed between the Administrations/RPOAs concerned.
.PP
Certain of the tests identified in the test list as compatibility test
may disturb the operation of the exchange, whereas others may not. Any
tests
which may cause disturbance to the exchange should be carefully selected to
meet the operational criteria of the two Administrations/RPOAs.
.PP
The satisfactory completion of compatibility testing should be
bilaterally agreed.
.PP
When a change to the signalling network is made, tests selected from those
identified as compatibility tests may be appropriate. In general the
tests performed under these circumstances will be the minimum number to
ensure that compatibility between points in the network is still maintained.
.PP
In compatibility testing, each signalling point may in turn consider itself
to be SP\*QA\*U, i.e.\ tests are performed on both signalling points
involved.
.RT
.sp 1P
.LP
5.3
\fITest configuration\fR
.sp 9p
.RT
.PP
For both validation and compatibility testing the point under test is connected
to the test environment and becomes part of the \*Qtest
configuration\*U. The test configuration satisfies all of the following
three criteria:
.RT
.LP
\(em
The point under test will be connected by one or more
signalling linksets (real or simulated), which may or may not be
interconnected.
.LP
\(em
The capability of generation and reception of test traffic, where applicable.
.LP
\(em
The ability to perform the described test, notably the
facility to store and analyze messages to the appropriate degree.
.sp 2P
.LP
\fB6\fR \fBFunctional requirements imposed by the test specification\fR
.sp 1P
.RT
.PP
The functional description that follows is intended to identify the functional
requirements imposed by the test specification. It does not imply
any physical partitioning of equipment in real systems. See also
Recommendation\ Q.701, \(sc\ 2.2.1.
.RT
.sp 1P
.LP
6.1
\fILevel 1\fR
.sp 9p
.RT
.PP
The test specification assumes the availability of a suitable
signalling data link with the parameters identified in the relevant
Q\ Recommendations, e.g.\ Q.702 (referring to Recommendation\ G.821).
.PP
In validation testing the signalling data link may be a
pseudo\(hysignalling data link, in which case it should preferably have
similar/identical
characteristics to the signalling data links likely to be encountered in
service. Simulation of deterioration of the transmission link may not be
necessary if the emulator includes the capability to simulate abnormal
conditions on the signalling data link.
.PP
In compatibility testing the signalling data link is the actual
signalling data link that will be used in service.
.bp
.RT
.sp 1P
.LP
6.2
\fILevel 2\fR
.sp 9p
.RT
.PP
The level 2 test environment consists of four items (see
Figure\ 1/Q.780):
.RT
.LP
\(em
the level 3 simulator;
.LP
\(em
the test simulator;
.LP
\(em
the signalling link monitor (see \(sc 7);
.LP
\(em
the signalling data link.
.sp 1P
.LP
6.2.1
\fILevel 3 simulator\fR
.sp 9p
.RT
.PP
During the level 2 tests it is necessary to inject signalling
messages and indications to and from the level\ 2 under test. It is desirable
that the level\ 3 function used is the actual level\ 3 of the MTP with some
additional functions for test purposes.
.RT
.sp 1P
.LP
6.2.2
\fITest simulator\fR
.sp 9p
.RT
.PP
During level 2 testing it is necessary to inject some abnormal
signal units (as well as normal signal units) to fully test the level\
2 under test, the test simulator should have this function. In addition
the simulator should have the capability to receive and check signal units
from the level\ 2 under test. The generation of certain abnormal sequences
of signal units should also be a capability of the test simulator.
.RT
.sp 1P
.LP
6.3
\fILevel 3\fR
.sp 9p
.RT
.PP
The level 3 test specification assumes that the level 2 has already been
tested satisfactorily. However, certain tests will in addition explicitly
test the level\ 2/3 interface.
.PP
The level 3 test environment consists of 3 items (see
Figure\ 2/Q.780):
.RT
.LP
\(em
the simulator of upper levels;
.LP
\(em
simulated network including test simulator and signalling
data links;
.LP
\(em
the signalling link monitor(s) (see \(sc 7).
.sp 1P
.LP
6.3.1
\fISimulator of upper levels\fR
.sp 9p
.RT
.PP
During level 3 testing it is necessary to inject signalling
messages into level\ 3 for testing, e.g.\ message loss during changeover.
It is desirable that the simulator used should be as close as possible
to the actual upper level to be used. In addition an MML interface is assumed.
The level\ 3
under test must use an already tested level\ 2.
.RT
.sp 1P
.LP
6.3.2
\fISimulated network including test simulator\fR
.sp 9p
.RT
.PP
During level 3 testing it is necessary to inject some abnormal
messages (as well as normal messages) to check the level\ 3 under test, the
simulated network including test simulator should have this function. In
addition the test simulator should have the capabilities to receive and
check messages from the level\ 3 under test. The generation of certain
abnormal
sequences of messages should also be a capability of the test simulator. The
test simulator must include an already tested level\ 2.
.RT
.sp 1P
.LP
6.4
\fITUP\fR
.sp 9p
.RT
.PP
The TUP test specification assumes a tested MTP for compatibility tests
but no assumption is made about message transfer between the TUP under
test and the TUP tester for validation tests.
.PP
The TUP test environment consists of three items (see
Figure\ 3/Q.780):
.RT
.LP
\(em
the TUP tester;
.LP
\(em
a stable signalling relation and telephone circuits;
.LP
\(em
a monitor of TUP messages and telephone circuits.
.sp 1P
.LP
6.4.1
\fITUP tester\fR
.sp 9p
.RT
.PP
The TUP tester is required to simulate TUP protocol operations and some
exchange call control operations.
.bp
.RT
.sp 1P
.LP
6.4.2
\fIMonitor\fR
.sp 9p
.RT
.PP
The monitor is required to monitor and record TUP message sequences and
to monitor the result of call control operations on the controlled
telephone circuits. This includes checking that tones are correctly received
and that speech/information transfer is possible.
.RT
.sp 2P
.LP
\fB7\fR \fBSignalling link monitor(s)\fR
.sp 1P
.RT
.PP
The test specification assumes the availability of a signalling
link monitor and a suitable access point for connection of the monitor as
specified in Recommendation\ Q.702, \(sc\ 4.
.PP
The test specification does not attempt to specify what a signalling link
monitor should be, but instead the functional requirements are identified
in general terms. A signalling link monitor will be used for decoding of
signal unit sequences during testing and to give the operator confidence
that the
signalling protocol has been correctly observed.
.PP
The requirements imposed on a signalling link monitor will be
different for the two types of testing. For validation testing detailed
decoding down to a field level will be required, but for compatibility
testing decoding down to a message level may be adequate.
.PP
In addition it should be noted that compatibility testing will be a
function performed numerous times on a signalling point, whereas validation
testing will be performed once only, except under certain circumstances of
upgrading of the signalling point.
.PP
\fINote\fR \ \(em\ It should be oserved that implementations may include a
signalling link monitor as an intrinsic part of the signalling point, however,
for validation testing this cannot necessarily be relied upon. In addition,
the test specification does not attempt to perform the function of testing
the
accuracy of any signalling link monitor implemented in the signalling point,
however, certain conclusions will inevitably be made from the performance of
validation testing.
.RT
.LP
.rs
.sp 20P
.ad r
\fBFigure 1/Q.780, (N), p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 27P
.ad r
\fBFigure 2/Q.780, (N), p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 20P
.ad r
\fBFigure 3/Q.780, (N), p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp